Modules Should Be Deep
TL;DR
モジュールは「深く」設計すべき。シンプルなインターフェースの裏に多くの機能を隠すのが良い設計であり、クラスや関数を細かく分けること自体は正義ではない。 「使う側の負担を最小にしつつ、裏側でできるだけ多くの仕事を引き受ける」のが理想。
4.1 Modular design
ソフトウェア設計の原則の一つ「モジュールは「奥深く」あるべき」という主張
「奥深い」とは、多くの機能性を提供しつつも、シンプルなインターフェースを持つことを指す
理想的な世界では、各モジュールは他のモジュールから完全に独立しているだろう。開発者は他のモジュールについて何も知らなくても、どのモジュールでも作業できるはずだ。そのような世界では、システムの複雑さは最も複雑なモジュールの複雑さに等しくなる。
モジュールは互いの関数やメソッドを呼び出すことで協調しなければならない。
モジュール同士はある程度互いのことを知っている必要がある
モジュール設計の目標は、モジュール間の依存関係を最小化することである。
4.2 What’s in an interface?
インターフェースとは、別のモジュールで作業する開発者がそのモジュールを使うために知っておくべきすべての情報
インターフェースはモジュールが「何をするか」を記述するが、「どのようにするか」は記述しない。実装とは、インターフェースで約束された内容を実現するコードである。
モジュールのインターフェースには、形式的（formal）なものと非形式的（informal）なものの2種類の情報が含まれる。
形式的
プログラム言語としてチェックできるもの
シグネチャーとか型など
非形式
プログラム言語としてチェックできない。高レベルの振る舞いが含まれる。クラスの使用に制約がある場合（たとえば、あるメソッドを別のメソッドより先に呼び出す必要がある場合など）、それもクラスのインターフェースの一部である。
依存関係とかがこれかなrkasu.icon
フロントエンドでいうと例えば型定義をみてもそれ以外の振る舞いが実際にはあるみたいなケース コメントで補完したりすることは重要っぽい
4.3 Abstractions
内容的にはほぼ具体と抽象の話だったrkasu.icon 抽象化するときは重要ではないものを省く
でもこの選択を謝ると誤った抽象化になってしまう
抽象化しないといけないものを省略しちゃうとか
その逆も
私たちの生活にも抽象化されたものはある
車の運転
冷蔵庫
最良のモジュールは深い（deep）モジュールである。シンプルなインターフェースを通じて多くの機能にアクセスできる。浅い（shallow）モジュールとは、比較的複雑なインターフェースを持ちながら、機能はそれほど多くないもののことである。つまり、多くの複雑さを隠蔽していない。
https://gyazo.com/45455b700c7adf767633494a0f257b14
A Philosophy of Software Design 4. Modules Should Be Deep 4.3 Abstractions p22(電子版)
4.4 Deep modules
深いモジュールはとてもいい
渡すパラメータが少ないけどモジュールでやってくれることが多い（複雑なことをやってくれる）
浅いモジュール
内部的にあんまり複雑ではないけどやたら渡すパラメータが多い
大量のPropsとかそうかもrkasu.icon
浅いモジュールの例だとラッパー的なコンポーネントとか関数とか？
Unixのfile I/0の仕組みとかが深いモジュールのいい例 4.5 Shallow modules
浅いモジュールとは、提供する機能に比べてインターフェースが相対的に複雑なもの
連結リストを実装するクラスは浅いモジュール
その機能のすべてがインターフェースを通じて見えてしまうのはよくない
4.6 Classitis
あまり深いクラスを実装していく価値がある認識がまだ薄い
小さくあるべきという考えがあり間違ったモジュールを作ってしまう
4.8 Conclusion
モジュールを設計するときは、使う側の負担を最小にしつつ、裏側でできるだけ多くの仕事を引き受けろ的なことだな